The client-server model of computing is a distributed application structure that partitions tasks or workloads between the providers of a resource or service, often called servers, and service requesters, often called clients. Generally, clients and servers communicate over a computer network on separate hardware, but both the client and the server may reside in the same system. A server host runs one or more server programs that share their resources with clients. Systems constructed with clients and servers enjoy widespread application on the Internet. One or more clients may interact with the server-side by connecting to it in order to obtain services to satisfy the clients' needs. A client frequently needs to synchronize its configuration with a server. When a configuration changes, the client needs to be notified in some way to update its configuration. However, complicated configuration changes and large numbers of clients (sharing a same server) usually make the required configuration updates, notifications, and synchronizations much more complicated, especially for a lightweight cluster architecture system, where adding a special configuration synchronizing module will unequivocally increase server-side burdens and workloads.
Conventionally, the following solutions have been used to solve the issue of configuration synchronization:
1. Set a configuration synchronizing module at the client to periodically send join queries. The client in this solution requires separate installation of a configuration synchronizing module, and when there are a large number of clients, additional burdens from processing new connections will be disadvantageously added to the server.
2. A server proactively pushes configuration information. In this solution, when the configuration associated with a client changes, the server proactively pushes configuration information to the client-side. The server-side in this solution requires the installation of an additional module for maintaining clients' information that is registered in the system.
3. A client and a server maintain a long transmission control protocol (TCP) connection. This solution is actually a variant of solution 2 above, where a list of clients registered in the system needs to be maintained. However, a long TCP connection itself is not reliable because the long connection can be interrupted by timeouts generated by intermediate equipment on the network.
4. Use a separate controller to issue configuration changes to the clients. This solution is also a variant of Solution 2 that pushes information to the clients, and in which a list of clients who have registered to the system needs to be maintained. Maintaining the separate controller is also required, which is not suitable for a lightweight cluster architecture system. Moreover, once the controller crashes, the whole system unfortunately crashes.
Therefore, all of the solutions discussed in the foregoing are focused on how to implement synchronization of the configurations. Maintaining an associated module is required regardless of whether the mechanism is querying or pushing modes. When a series of certain services needs to be synchronized with multiple clients, changes in the configurations may make the notifications of such changes and synchronizations even more complicated. Hence, a united method to process different changes in configurations is required.